Data communications in packet switched (PS) networks includes the transmission of data over a network as a sequence of small data chunks or suitable sized data blocks called packets. Each packet is passed through the network from a source (e.g. a user equipment (UE), terminal, mobile device, or other network entity) to a destination (e.g. another UE, terminal, mobile device, or another network entity) via one or more network entities or nodes. Each packet typically includes a data payload, which is a small chunk of the data being transmitted, and a packet header, which typically provides information such as the destination and/or source address and the type of packet or communications protocols being used.
PS networks may comprise or represent a communication network that groups all transmitted data into suitable sized data blocks called packets. Examples of specific PS networks that may be used in certain embodiments of the described network include, but are not limited to, legacy PS networks such as the second generation (2G), 2.5 generation (2.5G), third generation (3G), and fourth generation and beyond (4G and beyond) type networks, and/or evolved packet switched (EPS) networks, and/or all internet protocol (IP) based PS networks.
For example, the so-called Universal Mobile Telephone System (UMTS) (a legacy PS network commonly known as a 3G radio communication system) is a PS network standard that has evolved into using enhanced PS network technologies such as High Speed Packet Access (HSPA) technology. In addition, air interface technologies within the UMTS framework have begun to evolve towards new air interface technologies defined in the so-called Long Term Evolution (LTE) and LTE-Advanced systems.
The next generation radio communication systems and networks such as LTE and LTE-Advanced are considered to be all IP networks. These networks will have an upgraded PS network infrastructure called the evolved packet system (EPS). The EPS includes an evolved packet core (EPC) that forms the basis of the core PS network for the all IP network. These enhanced PS networks will provide all the mobile core functionality that, in the previous generations (2G, 2.5G, and 3G), has been realised through the existing CS networks and legacy PS networks.
The UE may comprise or represent any device used for communications. Examples of a UE that may be used in certain embodiments of the described network are wireless devices such as mobile phones, mobile devices, terminals, smart phones, portable computing devices such as lap tops, handheld devices, tablets, netbooks, computers, personal digital assistants and other wireless communication devices, or wired communication devices such as telephones, computing devices such as desktop computers, set-top boxes, and other fixed communication devices.
A network element or entity may comprise or represent any network node, device, function, or entity for use in a telecommunications network which can be managed over a specific interface. Examples of network elements or entities that may be used in certain embodiments of the described network(s) are network elements, nodes, devices, functions, or entities that make up core network(s), access network(s) such as packet or circuit switched network(s), IP based networks, 2G, 3G, 4G and next generation networks, IMS core network, IMS service network, and service and external networks and the like.
Data communications has evolved to use many different communications protocols or standards (e.g. Internet Protocols, TCP/IP protocols, UDP protocols etc.) for use in transmitting data from a source to the destination. These communications protocols may be layered in a so-called protocol stack in which a layer of the protocol stack serves the layer above it and the layer below it.
Typically a protocol stack includes an application layer, a transport layer and a network layer. The application layer includes logic needed to support various user applications or application programs, the transport layer includes mechanisms to provide reliable communication of application data controlled by the application layer, and the network layer is concerned with exchange of data between the source and the destination or the physical devices in the network. Examples of protocol stacks include the TCP/IP protocol suite (providing application, transport, internet, network access, and physical layers) or the open systems interconnection (OSI) model (providing application, presentation, session, transport, network, data link, and physical layers).
Data communications such as wireless and/or wired communications is becoming ubiquitous in many parts of the world. As communication network technology, UE capabilities, and applications advance and proliferate, ever-increasing amounts of data are being transmitted or transferred between UEs and communication networks. The ever-increasing amounts of data being transmitted will put pressure on the capacity and throughput of current and future communication network technologies. For example, many modern wireless communication networks are capacity-limited; decreasing the amount of data transferred between each UE and the communication network will improve overall performance and system capacity.
FIG. 1 illustrates the structure of an example packet 100 including a packet header 102 followed by the packet payload 104. In this example, the packet header 102 includes an Internet Protocol (IP) header 102a and a transport protocol header 102b (e.g. a TCP/UDP header). The packet payload 104 includes higher layer protocol information and the data or data chunk being transmitted. In order to provide reliable communications, data is passed between the layers in the form of packets, in which at each layer may insert additional data related to that layer to the payload of a packet and a header related to that layer. This means that packets may include one or more packet headers (e.g. IP header 102a and TCP/UDP header 102b) associated with the various communications protocols and/or layers of the protocol stack that may be used when communicating the data from the source to the destination. The headers depend on where in the network or at what level/layer (e.g. application layer, transport layer, or network layer) of the communication protocol or system the packet data is situated. It is to be appreciated that the example packet 100 and header 102 and payload 104 have been described for simplicity and by way of example only, in terms of the transport protocol layer (e.g. IP header 102a and TCP/UDP header 102b). The person skilled in the art would understand that the description herein applies to any packet including any header and any payload and may be based on any protocol or layer.
Transmission efficiency of packets may be increased by compressing the packets before transmission. There are many compression methods/algorithms that may be used for compressing packets. Typically, file compression methods/algorithms or compression method/algorithms treat packets as bit streams and operate to compress the bit streams. Such compression algorithms may include a compressor function and a corresponding de-compressor function. For example, the GNU's Not Unix (GNU) ZIP or GZIP is one of the many software application or compression algorithm for file compression and decompression. GZIP uses Lempel-Ziv coding (LZ77) lossless compression combined with Huffman entropy coding.
The GZIP compression algorithm is used by way of example only and for simplicity due to the plethora of compression/decompression algorithms available, it is to be appreciated a person skilled in the art would understand that the present invention is not so limited and that any suitable compression method/algorithm and/or decompression method/algorithm may be used.
Conventionally, the packet 100 may be compressed by performing compression on the packet header 102 and packet payload 104 separately. Most of the packet header information is either static or can be updated according to predictable patterns. As packet headers only include textual information fields, they can be easily compressed to increase transmission efficiency. Conventionally, packet headers in packet traffic transmitted over a network are compressed by analysing the header(s) of each packet to determine the number of bits that are to be compressed. For example, when applying packet header compression, the packet header is analyzed in detail, and specific packet header fields are divided into static, semi-dynamic and dynamic fields. In this case the packet header shall be treated as a bit stream without making specific considerations about the header, except for limiting the compression range to cover the bits of the header. For example, a compression method/algorithm such as GZIP may be applied to specific parts of a bit stream, such as packet headers.
There are various protocol header formats that may be used in a packet header 102, for example, various transport and IP protocol header formats may be based on the User Datagram Protocol (UDP) protocol, Internet Protocol version 4 (IPv4) protocol, Internet Protocol version 6 (IPv6) protocol, and Transmission Control Protocol (TCP). It is to be appreciated that these example protocol header formats (e.g. UDP, IPv4, IPv6, and TCP) have been described for illustration purposes and by way of example only; the person skilled in the art would understand that the description herein applies to any header format or even any payload independent of the protocol used for defining the packet. The sizes of the headers for these different IP level protocols are shown in Table 1.
TABLE 1Example IP level protocol headers and sizes.Protocol header Optional fields, (size) [bytes]size [bytes]IPv4 (20)Options (20-60)IPv6 (40)Extension headersUDP (8)TCP (20)Options (0-40)
It is apparent that each protocol uses a different header format that has a different size. In the header, the IP version is visible in the “version” field in the IP header, and the underlying transport protocol is also given in the IP header. To efficiently compress the a packet header 102, analytical methods for identifying the size of headers may be used such as IP packet inspection (PI), which may be sufficient to identify which protocols are being used over a specific connection and hence estimate the packet header size of each packet 100.
In addition, the packet payload 104 of a packet 100 may be compressed using compression methods/algorithms working on packet data traffic. For example, a compression algorithm such as GZIP or similar can be adopted. There exist different payload compression methods, some compressing individual data packets and others working across data packet boundaries (rather considering a flow of packets as a bit stream), while others compress entire data packets and others apply compression on specifically selected parts of data packets. In that last perspective a selected part can be specific packet headers like in many header compression algorithms. Such compression algorithms include a compressor function and a corresponding de-compressor function.
Typically, when the payload 104 above the transport level is not compressible, the compression ratio, which may be defined as the ratio of the compressed packet size to the uncompressed packet size, will not improve beyond compressing the packet headers 102. For example, there is no benefit compressing the payload 104 when encryption using Transport Layer Security (TLS) is used. However, if data above the transport layer is not encrypted then the data may be highly compressible depending on the type of data, for example, application layer signaling and overhead. Again, to efficiently compress the packet payload 104, analytical methods for identifying the type of payload and size of the payload may be used such as PI.
PI may comprise or represent the analysis of packets at different levels, from IP header classification to the deep packet inspection (DPI). The following describes some of the different levels of packet inspection and analysis that may be performed; these include, but are not limited to, IP header classification, shallow inspection, DPI, and heuristic detection.
IP header classification (a.k.a. 5-tuple inspection) is used to inspect packets up to the Internet layer, the so-called 5-tuple (Source IP address, Source IP port, Destination IP address, Destination IP port, Protocol (which runs on Transport layer, e.g. TCP, User Datagram Protocol (UDP), etc.) IP header classification is useful for identifying traffic targeting a specific port number, or a specific protocol. It is also useful when traffic from certain traffic domains, e.g. the Internet or Virtual Private Networks (VPNs), shall be treated in a specific way. For example, giving all Internet traffic a certain quality of service treatment (e.g., priority) or adding a different security protocol to a VPN.
Shallow inspection (a.k.a. Stateful inspection) is an analysis of the Transport Level protocol state, by inspecting the current protocol header (TCP, UDP etc.). For example, analysing the sequence of TCP header flags like SYN, ACK and FIN tells the state of the connection, and the receiver window size. Shallow inspection is useful when link layer algorithms are triggered by sequences of events of higher layer protocol interactions, without the need of knowing what content is carried. One example of use is to decrease the user terminal battery consumption by letting lower layer protocol states follow higher layer protocol layers. Shallow inspection also includes the analysis of all the fields of the IP header.
Deep packet inspection (DPI) is an analysis of data content on the Application Layer, e.g. hypertext transfer protocol (HTTP) state, video frame content, etc. One common example where DPI is used is caching, where the HTTP request is analysed to identify which content to fetch from the cache. Link layer algorithms can also be made to adapt to specific types of content or applications.
Heuristic detection includes pattern detection or statistical identification methods on Application Layer data. Typically needed for classification of services with encrypted content, or for applications that intentionally tries to avoid identification (e.g., to avoid blocked of free voice of IP applications).
Conventionally, due to the large variation of possible packet headers and payloads in packet traffic transmitted over a network, PI needs to be performed on each packet when applying packet header and packet payload compression. The packet header and/or packet payload has to be analyzed in detail. PI may be used to determine the length of a packet header 102 such that the header may be compressed using packet compression algorithms prior to transmission. Similarly, PI may be used to determine the length of the packet payload 104 such that the payload may be compressed using packet compression algorithms prior to transmission. The header length may represent the number of bits or bytes of the packet header, and payload length may represent the number of bits or bytes of the payload.
Given the sheer number of packets being transmitted in a network, performing PI such as IP header classification, shallow inspection, DPI, and/or heuristic detection for each packet in order to determine the packet header length and packet payload length that are compressible is becoming infeasible. This is due to the large amount of packet traffic, the computational resources required for PI on each packet due to insufficient hardware or software (e.g. UEs), and/or the delays incurred for performing PI on each packet. In addition, trying to compress an entire packet 100 while only a fraction of may be compressible demands an unnecessarily large computation effort when the whole packet is to be compressed. In some situations, it may be desired to only compress headers 102 and not the payload 104 part of a packet 100. However, in other situations, the payload may be compressible and thus both header and payload compression may be desired to reduce bandwidth usage and improve throughput in the communication network. Thus, PI is typically required to determine which parts of a packet 100 are compressible and which parts are not compressible. It is apparent that either compressing the entire packet when only a fraction is compressible or using PI functionality to observe the content of the packets requires a lot of unnecessary computational effort. Therefore, there is a significant need to optimise the compression and decompression of packets for packet traffic in the network while minimising the computational resources and delays in transmitting packets in the network and maximising bandwidth efficiency and throughput of data transmission in the network.